- New base test description for structure
- This one will contain customization and have no data (to verify some
  basic implementation details).
- Changed setup for first test to be JSON format for better syntax
  visualization.
- Empty body.html added to afterEach for cleanup (test teardown).

Paste button no longer required to exist.

- Ensure that a missing paste button will prevent the table from being
  rendered.

Ability to customize the cookie for columns

- Define a new key "activeColumnsCookie" for structure.
- This enables view specific column settings (i.e. a view on a list of
  users may have sufficiently different columns such that the settings
  for folder_contents shouldn't apply or interfere with at all).
- Needed adjustments in the view and template for tablerow to prevent
  rendering from being aborted to missing data.
- Still need a bare minimum set of attributes being available (i.e.
  Title and getURL).

Formalize definition of nested params in structure

- Provide default parameters with the _default_ prefix.
- Replace the demoButton with _default_buttons to be consistent.
- Provide a generalized helper function for the replacement of the
  object/array type options for the structure pattern.
- First usage on this is to write more tests, in this case document that
  the buttons can be completely replaced, or even completely removed.

Test for per item dropdown action menu click

- Ensure that at least one of them works (move-top).
- See that the defaults will continue to work when changes to migrate
  generation of the items and bindings are moved to a more configurable
  definition.
- Make it actually do the full round trip including the existing button.

Initial split of Actions from ActionMenu

- Per-item action methods should not be defined directly within the view
  class; view class should only deal with rendering/registration of the
  events, and those events should be registered within a seaparate model
  which this view class should make use of
- Baby steps: want to make it possible to hook in events that could be
  defined by other libraries.

Hooking in the event with requirejs

- Provide a way to specify dynamically where the modules are for a given
  event along with the label.

Configurable menu options.

- Move option visibility logic out of template
- Instead, construct the table for this shared between the event method
  and the template.
- Enable the user-specifiable option for the template.
- Include a test for the customization of action menu.
- Pass down menu option into current folder actions

Have action menu tests define/use custom modules

- Show that the internal procedure of requiring/using modules loaded via
  requirejs functions as expected.

Hook moveUrl to the availability of rearrangement

- Don't apply the rearrange class to the parent of the table if that was
  not provided in the constructor.
- Also don't provide the move-top and move-bottom actions for that case.

Ability to specify action at the table level

- Add in tests to ensure correctness of existing work.
- Still need to figure out how to do this at the per item level.

Various per item actionmenu tests

- Fixed the missing entries when used (have to clone that object because
  javascript).
- Actually add in the tests for the functionalities for those actionmenu
  items to ensure that they are triggered to ensure they stay correct.
- Verify certain xhr requests.

Split up the navigation stuff

- getWindow now a utility function - make it stubbable because assigning
  window.location will result in test framework triggering a disconnect.
- Have the new module that only deal with general navigation such as
  opening a link.

User provided link click handlers

- The actions for handling folder and standard item clicks can be
  defined similar to how actionmenu was done.
- Removed all the extraneous methods that were duplicated for this in
  the previous commit(s).

Do a proper integration test for actionmenu.

- Show that it works from within a table also.

Split up ActionMenu into view and menu component

- Renamed existing ActionMenu to ActionMenuView (maintaining consistency
  with other js files).
- Split out the default ActionMenu generation functionality into its own
  module.

Assign menuOptions iff menuGenerator return object

- Prevent some basic configuration failure cases - at least show data
  even if action menu might be missing.

Finalize menuGenerator integration

- This allow the generator to be specified at the app level
- Test demonstrates how menu can look into each model for given row to
  generate the appropriate actions.

Check that unselect actually unselect stuff

- Find out that if the raw data is missing the id attribute for a given
  item, the de-selection will not be able to unselect the checkbox.

Testing selectAll within a folder in table

- Show that this functionality also work, but the intial test data had
  to be manipulated
- Also had to reset the queryHelper, because the currentPath is not
  properly cleansed between tests.
- Tests that relied on the above had to be adjusted to go back down to
  the expected currentPath.

- This was done to clarify the scope and hierarchy of the affected
  objects.

- The AppView instance is where the path setting should be done, even
  though it ultimately pokes into the methods by the same name within
  ResultCollection.

  - Code that previously used queryHelper.currentPath now delegate this
    through the methods provided by AppView.

- Formalizing what needs to be implemented for custom ResultCollection
  models - it needs to provide getCurrentPath/setCurrentPath along with
  the relevant Backbone.Paginator.requestPager methods.  This should be
  documented.

  - The instance of AppView.collection now keeps track of the path that
    the AppView should be on - no longer requiring fetching this value
    from queryHelper

- A completely custom ResultCollection can be now provided.  It does not
  need to follow the existing usage of the QueryHelper/Parser class as
  custom implementations don't need to deal with the Plone Catalog.

- Default ResultCollection implementation now constructs queryParser and
  queryHelper inside itself to keep as much of the Plone catalog and
  content type specific information out of the pattern itself to aid in
  allowing reuse without the unwanted Plone bits (specifically with the
  queryHelper stuff, it really had no place on the top level option
  object).

- Default implementation of the queryParser and construction of
  queryHelper should remain unchanged except for its references to
  certain attributes that exist on the parent app objects (such as the
  AppView.toolbar).

Formalize the previous changes with a final test.

- Created a test that cover the case where the QueryHelper (and
  collection.queryParser) is triggered, such that they together should
  generate the correct query parameters for consumption by the
  vocabulary endpoint within a Plone instance.

- The test also serves to finalize the clarified version of the object
  relationships between the structure pattern, AppView, ResultCollection
  and QueryHelper.  The previously tangled web of relationships
  (specifically the setting/access of the current path to be
  accessed/represented by the structure view) is more controlled.

- To really hammer in this point, AppView has an instance of
  ResultCollection, and it gained complete ownership of QueryHelper as
  it utlimately controls what gets populated inside the table, despite
  how QueryHelper needs to have access to the certain attributes of the
  pattern itself.

Ensure that the selectAll option work still

- Moving the queryHelper into the collection broke that, turns out this
  wasn't tested before.

- For the link that opens a new window, there will be cases where the
  view suffix is not desirable.  This allows the data source to provide
  an explicit one.  Fallback behavior is what it was before.

- This change ensures that it is possible to trigger the events off the
  correct base url as the views will not have the actual real views that
  would have been resolved by the event.
- Ensure that the push/popstates are properly handled/triggered.

Also more tests for window pushState

- Added the configuration needed to trigger that.
- Added the required window mocks to allow the pushState to be tested.
- Ensure that the URL argument passed is as expected.

- Provide an alternative way to set the pushState url, using a format
  string that make use of the {path} token for substitution as an
  alternative to the somewhat more opaque urlStructure parameter.